The secret to SAP B2B e-commerce success

For years our sales pitch has been that if you gIve us VPN (virtual private network) access to your SAP® landscape we’ll integrate our cloud based service to your SAP® system in a matter of hours and we’d be 80% done on day one of your SAP® Integrated B2B ecommerce project.*  In fact, that’s how we start every one of our projects.  We run a facilitated Project Initiation Workshop that reviews a live Corevist application running against your SAP® QA system and we repeatedly ask stakeholders, screen by screen, “why can’t this application go into production tomorrow?”.  I facilitated one of these workshops last week and today I’m going to present proof that we are indeed about 80% done on day one.

Over a two day period these Project Initiation Workshops typically generate in between 100-120 reasons why in fact that application “can’t go into production tomorrow”.  That’s the whole point of the exercise, to generate these change requests which become our prioritized punchlist to GoLive success.  Last week’s workshop produced 103 of these documented change requests distributed by category as follows:

The slice of the pie to focus on is the 16% of Change Requests in the “Feature Request” bucket.  These are the items that are truly unique to this client and require either customizing, or extending, the base Corevist platform.  In this particular case, they are requests such as:

1. Process credit cards – in this case, the client uses an offline 3rd party payment provider that we don’t currently support.  If they had used BluePay, Paymetric, authorize.net, Chase PaymentTech, WorldPay, we’d be good to go.  This request went on the backlog since the client agreed that they’re happy to golive without it.  But everyone is on notice that it is a strong contender for Phase 2.
2. Search for Orders via Color/Style – our out of the box services queries orders by SAP® Material Number.  Website users won’t know the SAP® # but do use an industry standard combination of attributes of which Color/Style are the most important.  This is a high priority requirement and the website can’t be launched without it.
3. We have multiple outputs per shipment. Replace BOL with Shipment Confirmation output type (ZBOL or ZBLC). Based on shipment type we’ll decide.  This is going to require some business logic to be developed to determine under which conditions to display which output type.

The other categories are defined as follows:

• Training (2%) – these are items that are potentially confusing enough to require the creation of training material for the website users.  An example of this on this project is “provide guidelines for userid selection”.
• Client Policy (4%) – We uncover these items in every one of our workshops.  They are decisions that the client has to make in order for the project to proceed but require no additional work on Corevist’s part.  On this project, “should we have to force users to accept Terms and Conditions on every order during checkout?”, is an example.
• Comments (9%) – These are just tidbits of knowledge that are conveyed during the workshop but are strictly meant to inform the project team but don’t present anything actionable for Corevist.  An example of this on this project would be: “Statements are no longer being mailed out to customers.  If we’re going to provide them electronically on the web (which is a great idea and Corevist provides out of the box) we may want to validate that they are still being produced as expected.”
• Configuration (45%) – These change requests are all anticipated by the Corevist platform and are easily accommodated on the project.  They are items like: “add sidemarks at the line item and header level”, “change document date to order date”, “display return authorization document types” and “display ALL recently placed orders on the dashboard not just web orders”.
• Defects (7%) – These are items that aren’t behaving as expected during the workshop.  One of the defects uncovered in this workshop was “There should be a warning message issued that you didn’t order a full carton quantity”.  This one was particularly spooky since every SAP® warning and error message is simply conveyed to us and we display it on the web with appropriate translations if required.  In this case, the error was registered in VA01 but not showing up on the web.  My guess is that the error message is generated by an SAP® user exit that wasn’t coded in anticipation of being called from a BAPI from the web.  But it’s definitely a defect from the user’s perspective and has to be dealt with.
• Duplicates (3%) – Even the best of scribes can’t avoid writing down change requests that come up in conversation multiple times over a two day period.  But 3% isn’t a huge number :-).
• Scenarios (14%) – During the course of two days you hear all sorts of great ways that the website will be used.  We document them even though they really aren’t “change requests” because we want to make sure that we support them as we evolve the system.  These scenarios are the vehicles we use to demonstrate and test the system.  An example of one of these Scenarios is: “Customer places an order to be shipped to an address that is not a ShipTo in the Customer Master”.  Our dropship capability supports this out of the box so there is no work to be done on our part except to demonstrate that we support it.

In summary, after two days of intense scrutiny by a room full of stakeholders ranging from CSRs, SAP® Functional Experts, Finance Managers, and IT Management, the Corevist system is ready to go into production on day one except for 103 documented change requests.  Of those, 84% will be dispatched within days of the workshop’s end.  What remains is 16% of the change requests that will require more significant effort which will be evaluated in the days to come.  So, indeed, we’re 80% done on day one…in fact in this case we’re 84% done on day one.

Q.E.D.

Sam

*Therein lies the Corevist “secret sauce”.  Our B2B eCommerce application was designed from the ground up to work with SAP®.  So much so that it can’t operate as a standalone application and doesn’t work with any other ERP system.  Our integration is out of the box and our functionality, molded by scores of implementations, is fit for most purposes.